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Internet Control Message Protocol 


Introduction 


The Internet Protocol (IP) [1] is used for host-to-host datagram 
service in a system of interconnected networks called the 

Catenet [2]. The network connecting devices are called Gateways. 
These gateways communicate between themselves for control purposes 
via a Gateway to Gateway Protocol (GGP) [3,4]. Occasionally a 
gateway or destination host will communicate with a source host, for 
example, to report an error in datagram processing. For such 
purposes this protocol, the Internet Control Message Protocol (ICMP), 
is used. ICMP, uses the basic support of IP as if it were a higher 
level protocol, however, ICMP is actually an integral part of IP, and 
must be implemented by every IP module. 


ICMP messages are sent in several situations: for example, when a 
datagram cannot reach its destination, when the gateway does not have 
the buffering capacity to forward a datagram, and when the gateway 
can direct the host to send traffic on a shorter route. 


The Internet Protocol is not designed to be absolutely reliable. The 
purpose of these control messages is to provide feedback about 
problems in the communication environment, not to make IP reliable. 
There are still no guarantees that a datagram will be delivered or a 
control message will be returned. Some datagrams may still be 
undelivered without any report of their loss. The higher level 
protocols that use IP must implement their own reliability procedures 
if reliable communication is required. 


The ICMP messages typically report errors in the processing of 
datagrams, to avoid the infinite regress of messages about messages 
etc., no ICMP messages are sent about ICMP messages. 


Message Formats 


ICMP messages are sent using the basic IP header. The first octet of 
the data portion of the datagram is a ICMP type field; the value of 
this field determines the format of the remaining data. Any field 
labeled "unused" is reserved for later extensions and must be zero 
when sent, but receivers should not check these fields. Unless 
otherwise noted under the individual format descriptions, the values 
of the internet header fields are as follows: 
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Version 


IHL 


Internet header length in 32-bit words. 


Type of Service 
0 

Total Length 
Length of internet header and data in octets. 

Identification, Flags, Fragment Offset 
Used in fragmentation, see [1]. 

Time to Live 
Time to live in seconds; as this field is decremented at each 
machine in which the datagram is processed, the value in this 
field should be at least as great as the number of gateways which 
this datagram will traverse. 

Protocol 
ICMP = 1 

Header Checksum 
The 16 bit one’s complement of the one’s complement sum of all 16 
bit words in the header. For computing the checksum, the checksum 
field should be zero. This checksum may be replaced in the 
future. 


Source Address 


The address of the gateway or host that composes the ICMP message. 
Unless otherwise noted, this can be any of a gateway’s addresses. 


Destination Address 


The address of the gateway or host to which the message should be 
sent. 
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Destination Unreachable Message 


0 
0 


1 2 3 
den 36 A946 T 8 9-0: 1 23) 456 18. OO: 2 3A 6 T 89 Or 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Type | Code | unused | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Internet Header + 64 bits of Original Data Datagram | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IP 


Fields: 


Destination Address 


The source network and address from the original datagram’s data. 


ICMP Fields: 


Type 
3 
Code 
0 = net unreachable; 
1 = host unreachable; 
2 = protocol unreachable; 
3 = port unreachable; 
4 = fragmentation needed and DF set. 


Internet Header + 64 bits of Data Datagram 


The internet header plus the first 64 bits of the original 
datagram’s data. This data is used by the host to match the 
message to the appropriate process. If a higher level protocol 
uses port numbers, they are assumed to be in the first 64 data 
bits of the original datagram’s data. 


Description 


If, according to the information in the gateway’s routing tables, 
the network specified in the internet destination field of a 
datagram is unreachable, e.g., the distance to the network is 
infinity, the gateway sends a destination unreachable message to 
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the internet source host of the datagram. In addition, in some 
networks, the gateway may be able to determine if the internet 
destination host is unreachable. Gateways in these networks may 
send destination unreachable messages to the source host when the 
destination host is unreachable. 


If, in the destination host, the IP module cannot deliver the 
datagram because the indicated protocol module or process port is 
not active, the destination host may send a destination 
unreachable message to the source host. 


Another case is when a datagram must be fragmented to be forwarded 
by a gateway yet the Don’t Fragment flag is on. In this case the 
gateway must discard the datagram and return a destination 
unreachable message. 
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Time Exceeded Message 


0 1 2 3 

Oa n e E E E a a E SE E E a a O E E E E A 021 

+-+-+-+-+-+-+-+-+-+-+- ++ 
| Type | Code | unused | 
+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| Internet Header + 64 bits of Original Data Datagram | 
+-+-+-+-+-+-+-+-+-+-+-+- ++ 


IP Fields: 


Destination Address 


The source network and address from the original datagram’s data. 


ICMP Fields: 


Type 
11 

Code 
0 = time to live exceeded in transit; 
1 = fragment reassembly time exceeded. 


Internet Header + 64 bits of Data Datagram 


The internet header plus the first 64 bits of the original 
datagram’s data. This data is used by the host to match the 
message to the appropriate process. If a higher level protocol 
uses port numbers, they are assumed to be in the first 64 data 
bits of the original datagram’s data. 


Description 


If the gateway processing a datagram finds the time to live field 
is zero it must discard the datagram. The gateway may also notify 
the source host via the time exceeded message. 


If a host reassembling a fragmented datagram cannot complete the 


reassembly due to missing fragments within its time limit it 
discards the datagram, and it may send a time exceeded message. 
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Parameter Problem Message 


0 1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Code | Parameter | unused 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Internet Header + 64 bits of Original Data Datagram | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IP Fields: 
Destination Address 
The source network and address from the original datagram’s data. 
ICMP Fields: 
Type 


12 


0 = problem with option. 
Parameter 
If code = 0, IP option type. 
Internet Header + 64 bits of Data Datagram 


The internet header plus the first 64 bits of the original 
datagram’s data. This data is used by the host to match the 
message to the appropriate process. If a higher level protocol 
uses port numbers, they are assumed to be in the first 64 data 
bits of the original datagram’s data. 


Description 


If the gateway or host processing a datagram finds a problem with 
the header parameters such that it cannot complete processing the 
datagram it must discard the datagram. One potential source of 
such a problem is an option that is not implemented, or incorrect 
arguments in an option. The gateway or host may also notify the 
source host via the parameter problem message. 
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Source Quench Message 


0 
0 


1 2 3 
Le? 3-409 6-7 8° 9 0 12°34 n6 7°38 90 1-2-3456 7 89-0 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Type | unused | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Internet Header + 64 bits of Original Data Datagram | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IP 


Fields: 


Destination Address 


The source network and address of the original datagram’s data. 


ICMP Fields: 


Type 


4 


Internet Header + 64 bits of Data Datagram 


The internet header plus the first 64 bits of the original 
datagram’s data. This data is used by the host to match the 
message to the appropriate process. If a higher level protocol 
uses port numbers, they are assumed to be in the first 64 data 
bits of the original datagram’s data. 


Description 


A gateway may discard internet datagrams if it does not have the 
buffer space needed to queue the datagrams for output to the next 
network on the route to the destination network. If a gateway 
discards a datagram, it may send a source quench message to the 
internet source host of the datagram. A destination host may also 
send a source quench message if datagrams arrive too fast to be 
processed. The source quench message is a request to the host to 
cut back the rate at which it is sending traffic to the internet 
destination. The gateway may send a source quench message for 
every message that it discards. On receipt of a source quench 
message, the source host should cut back the rate at which it is 
sending traffic to the specified destination until it no longer 
receives source quench messages from the gateway. The source host 
can then gradually increase the rate at which it sends traffic to 
the destination until it again receives source quench messages. 
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The gateway or host may send the source quench message when it 
approaches its capacity limit rather than waiting until the 
capacity is exceeded. This means that the data datagram which 
triggered the source quench message may be delivered. 
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Redirect Message 


0 


1 


2 


3 


01234567890123456789012345678<901 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+- 


—-+-— 


+- 


+— + — +— + 


+- 


+ 


+ 


+ 


+ 


Type 


| Code 


| unused 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Gateway Internet Address 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Internet Header + 64 bits of Original Data Datagram 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IP Fields: 


Destination Address 


-+-+ 


-+-+ 


-+-+ 


-+-+ 


The source network and address of the original datagram’s data. 


ICMP Fields: 


Type 


Code 


2 


3 


Redirect 


Redirect 


Redirect 


Redirect 


datagrams for 
datagrams for 
datagrams for 


datagrams for 


Gateway Internet Address 


the Network. 


the Host. 


the Type of Service and Network. 


the Type of Service and Host. 


Address of the gateway to which traffic for the network specified 
in the internet destination network field of the original 
datagram’s data should be sent. 


Internet Header + 64 bits of Data Datagram 


The internet header plus the first 64 bits of the original 

This data is used by the host to match the 

If a higher level protocol 
they are assumed to be in the first 64 data 


datagram’s data. 
message to the appropriate process. 
uses port numbers, 


bits of the original datagram’s data. 
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Description 


The gateway sends a redirect message to a host in the following 
situation. A gateway, Gl, receives an internet datagram from a 
host on a network to which the gateway is attached. The gateway, 
Gl, checks its routing table and obtains the address of the next 
gateway, G2, on the route to the datagram’s internet destination 
network, X. If G2 and the host identified by the internet source 
address of the datagram are on the same network, a redirect 
message is sent to the host. The redirect message advises the 
host to send its traffic for network X directly to gateway G2 as 
this is a shorter path to the destination. The gateway forwards 
the original datagram’s data to its internet destination. 
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Echo or Echo Reply Message 
0 1 2 3 
0123456789012345678°9012345678<9 021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | unused 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Data 
+-+-+-+-+- 
IP Fields: 
Addresses 
The address of the source in an echo message will be the 
destination of the echo reply message. To form an echo reply 
message, the source and destination addresses are simply reversed. 
IP Fields: 
Type 
8 for echo message; 
0 for echo reply message. 


Description 


The data received in the echo message must be returned in the echo 
reply message. 
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Timestamp or Timestamp Reply Message 


0 1 2 3 
012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 

| Type | unused 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ HHHH 
| Originate Timestamp | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 
| Receive Timestamp | 
+ot—4-4-4-4F-4-4F-4-4F-4-t-t-t-t-4-t-4-t-4-t-4-t-t-t- tat tatitattat 
| Transmit Timestamp | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


IP Fields: 
Addresses 


The address of the source in a timestamp message will be the 


destination of the timestamp reply message. To form a timestamp 
reply message, the source and destination addresses are simply 
reversed. 

IP Fields: 

Type 


13 for timestamp message; 
14 for timestamp reply message. 
Description 
The data received (a timestamp) in the message is returned in the 
reply together with an additional timestamp. The timestamp is 32 


bits of milliseconds since midnight UT. One use of these 
timestamps is described by Mills [5]. 


[Page 12] 


April 1981 


RFC 777 


Summary of Message Types 


0 


3 


13 


14 


Echo Reply 

Destination Unreachable 
Source Quench 

Redirect 

Echo 

Time Exceeded 

Parameter Problem 
Timestamp 


Timestamp Reply 
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